Winzipper/Winzipper_ISO.iso/internet/net commander 1.0/PANORAMA/CATALOG.Z/OSF.DTD

Text File | 1995-07-24 | 79.3 KB | 2,279 lines

<!--
 _______________________________________________________________________
|                                    |
|    Version: Beta #2                        |
|                                    |
|    Document Type Definition for OSF books.                |
|                                    |
|    b                       k                    |
|    b                       k                    |
|    b                       k    k                    |
|    b                       k   k                    |
|    bbbbbb  oooooo  oooooo  kk k                    |
|    b    b  o    o  o    o  k k                    |
|    b    b  o    o  o    o  k  k                    |
|    b    b  o    o  o    o  k   k                    |
|    bbbbbb  oooooo  oooooo  k    k                    |
|                                    |
|_______________________________________________________________________|
-->

<!--
 _______________________________________________________________________
|                                    |
|   Copyright 1993 Open Software Foundation, Inc.,            |
|   Cambridge, Massachusetts.                        |
|                                    |
|   All rights reserved.                        |
|                                    |
|   Permission to use, copy, modify, and distribute this document for    |
|   any purposes and without fee us hereby granted, provided that the    |
|   above copyright notice and this permission notice appear on all    |
|   copies of this document.  The name of Open Software Foundation,    |
|   Inc. (OSF) may not be used in advertising or publicity pertaining    |
|   to this document without express, written prior consent.        |
|                                    |
|   OSF PROVIDES THIS DOCUMENT TO USER "AS IS."  OSF DISCLAIMS ALL    |
|   WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THIS DOCUMENT,    |
|   INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A    |
|   PARTICULAR PURPOSE.  IN NO EVENT SHALL OSF BE LIABLE FOR ANY    |
|   DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,    |
|   OR ANY DAMAGES WHATSOEVER RESULTING FROM LOS OF USE, DATA, OR    |
|   PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE, OR OTHER    |
|   TORTUOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OF    |
|   THIS DOCUMENT.                            |
|_______________________________________________________________________|
-->

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    General Entity declarations for use in the OSFDTDs        |
|_______________________________________________________________________|
-->

<!--
 _______________________________________________________________________
|                                    |
|    The following entity declarations list the low level markups    |
|    that will get combined into various entities further below.    |
|                                    |
|    Naming convention for these parameter entities:            |
|      g.*    Used in grouping components that have something in    |
|        common.  Typically, they'll be declared together or    |
|        combined in elements' content models.            |
|      s.*    Define groupings of semantic content (of * or *-type    |
|        things.  s.* is used in content models throughout.    |
|      *t*    Names with an extra 't' mean 'technical'.        |
|_______________________________________________________________________|
 -->


<!--....................................................................
|    General key data elements:                    |
 .....................................................................-->

<!ENTITY % g.text    "literal | emphasis | subscript | superscript"    >
<!ENTITY % g.name    "acronym | trademark | person | place | honorific" >
<!ENTITY % g.normal    "date | time | telephone | year | e-mail"    >
<!ENTITY % g.special    "number | msg-number | different-lang |
            calendar-ref"    >


<!--....................................................................
|    Technical key data elements:                    |
 .....................................................................-->

<!ENTITY % g.tname    "variable | keyboard-key | command | function |
            file | path | datatype"                >
<!ENTITY % g.io        "keyboard-input | computer-output | gui-text"    >
<!ENTITY % g.tspecial    "cmd-argument | data-declaration | option-name |
            misc-data | markup"    >
<!ENTITY % g.media    "graphic | audio | video"        >


<!--....................................................................
|    Paragraph- and phrase-like content.  This is all keydata    |
|    and PCDATA.  Used in most cases where "simple text" is        |
|    expected.  s.leaf is for general cases, s.tleaf for technical.    |
 .....................................................................-->

<!ENTITY % s.leaf
    "#PCDATA | %g.text; | %g.name; | %g.normal; | quote |
    address | author-info | input-instruct | msg-text | %g.special; |
    (%g.tname; | %g.tspecial; | %g.io; | logical-negation) |
    %g.media; | equation | special-format"
>

<!ENTITY % s.tleaf
    "#PCDATA | %g.normal; | input-instruct | msg-text |
    (%g.tname; | %g.tspecial; | %g.io; | logical-negation) |
    %g.media; | equation | special-format"
>

<!ENTITY % s.tbranch
    "%g.normal; | input-instruct | msg-text | %g.tname; | %g.tspecial; |
     %g.io; | logical-negation | %g.media; | equation"
>


<!--....................................................................
|    "Simple text" content, often specialized for a particular    |
|    semantic situation.                        |
 .....................................................................-->

<!ENTITY % s.date    "(#PCDATA)"                >
<!ENTITY % s.identifier    "(#PCDATA)"                >
<!ENTITY % s.text    "(#PCDATA | trademark | special-format)"    >
<!ENTITY % s.ttext    "(#PCDATA | %g.tname; | %g.tspecial; | special-format)" >
<!ENTITY % s.filename    "(#PCDATA | file | path)"        >
<!ENTITY % s.name    "acronym | trademark | person | place | honorific" >
<!ENTITY % s.normal    "date | time | telephone | year | e-mail"    >


<!--....................................................................
|    %s.branch; is used where structured content is allowed, such as    |
|    immediately within a division.  It can be thought of as        |
|    components that will further branch.  It gets widely used, as    |
|    structured text is a very general capability.             |
 .....................................................................-->

<!ENTITY % s.branch
    "p | list | table | display | note | excerpt | bridge-title"
>

<!--....................................................................
|    %s.pbranch; contains those s.branch things that may go inside    |
|    of a paragraph.                            |
 .....................................................................-->

<!ENTITY % s.pbranch    "list | table | display | excerpt"    >


<!--....................................................................
|    s.branch.text is intended for use where textual branching    |
|    components can go                        |
 .....................................................................-->

<!ENTITY % s.branch.text    "p | list | table | note"    >


<!--....................................................................
|    %s.everything; is used where blocks or regular text expected.    |
|    It allows branching things or leaf things, but not this mix    |
|    of both.                            |
 .....................................................................-->

<!ENTITY % s.everything    "(%s.branch;)* | (%s.leaf;)*"    >


<!--....................................................................
|    %s.display; is what can go inside a display. It is a superset    |
|    of s.branch.                            |
 .....................................................................-->

<!ENTITY % s.display
    "(%s.branch; | message | proglang-synopsis | cmd-synopsis |
      file-synopsis | return-code | text-as-figure | text-alternate |
      (%s.tbranch;) )*"
>

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Content of various levels of book divisions.            |
|_______________________________________________________________________|
 -->


<!--....................................................................
|    content of structural elements:                    |
 .....................................................................-->

<!ENTITY % div-general    "| division"    -- should be "" in the OSFDTD OUT -- >


<!--....................................................................
|    various prelim/frontmatter elements, with generic divisions:    |
 .....................................................................-->

<!ENTITY % s.prelim    "foreword?, preface?, pdivision*"    >

<!ENTITY % s.preface    "title, augmentum?, (%s.branch;)*, pdivision*"  >
<!ENTITY % s.pdivision    "title, augmentum?, (%s.branch;)*, pdivision*"  >
<!ENTITY % s.foreword    "title, augmentum?, (%s.branch;)*, pdivision*"    >

<!ENTITY % s.body    "part+ | ( chapter %div-general; )+"    >

<!ENTITY % s.part    "title, augmentum?, (%s.branch; )*,
                ( part* | osf-refpage* |
                 ( chapter %div-general; )* )" >
<!ENTITY % s.chapter    "title, augmentum?, ( %s.branch; )*,
                ( osf-refpage* | ( section %div-general; )* )"      >
<!ENTITY % s.section    "title, augmentum?, ( %s.branch; )*,
                ( division* | osf-refpage* )"  >
<!ENTITY % s.division    "title, augmentum?, ( %s.branch; )*,
                ( division* | osf-refpage* )"  >

<!ENTITY % s.supplement    "( appendix %div-general; )+"    >
<!ENTITY % s.appendix    "%s.chapter;"    >

<!--....................................................................
|    pdivision types                            |
 .....................................................................-->

<!ENTITY % pdivision-types
    "acknowledgements | applicability | audience | contents |
    conventions | document-map | document-structure | document-usage |
    problem-reporting | purpose | reader-feedback | related-documents |
    typog-conventions"    >

<!--....................................................................
|    chapter, section, division types                |
 .....................................................................-->

<!ENTITY % division-types
    "introduction | message | reference | summary"    >

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Content of various levels of reference divisions.        |
|_______________________________________________________________________|
 -->


<!--....................................................................
|    content of structural elements:                    |
 .....................................................................-->

<!ENTITY % rdiv-general    "| rdivision"    -- should be "" in the OSFDTD OUT -- >


<!--....................................................................
|    reference division elements (much simpler than book)        |
|                                    |
|    s.rbody is used to define the "body" of a refpage.        |
|    rsection is the equivalent to .SH, while rdivision, when    |
|    nested immediately below an rsection, is equivalent to a    |
|    .SS.  Note that rdivisions may nest.                |
 .....................................................................-->

<!ENTITY % s.rbody    "( ( %s.branch; )+ | ( rsection %rdiv-general; )+ )"    >

<!ENTITY % s.rsection
    "title, ( %s.branch; | proglang-synopsis | cmd-synopsis |
                            file-synopsis )*,
        ( rsubsection %rdiv-general; )*"    >

<!ENTITY % s.rsubsection "title, ( %s.branch; )*, rdivision*"    >

<!ENTITY % s.rdivision    "title, ( %s.branch; )*, rdivision*"    >

<!--....................................................................
|    rsection types                            |
 .....................................................................-->

<!ENTITY % rsection-types
    "AES-support-level | abbreviation | alias | arguments | bugs |
    cautions | description | diagnostics | errors | examples |
    exit-values | fields | files | flags | history-direction | library |
    notes | options | output | parameters |
    related-information | return-values | specification-context |
    subcommands | synopsis | warnings" >


<!--....................................................................
|    rsubsection types                        |
 .....................................................................-->

<!ENTITY % rsubsection-types "compatibility-level | support | support-level" >

<!--FF-->

<!--
 _______________________________________________________________________
|                                    |
|    The %common-attr; parameter entity defines attributes that are    |
|    common to all elements.                        |
|                                    |
|    qualify        describes how an element is qualified.     eg,    |
|            meant for a certain system, etc.        |
|                                    |
|    id        provides an id that may be #IMPLIED or        |
|            #REQUIRED depending on how %common-attr; is    |
|            used                        |
|                                    |
|    use of this parameter must be followed by something that ends    |
|    the id attribute, like #REQUIRED                |
|                                    |
|    The entity extra-common-attr may be set in an instance, so the    |
|    user can easily add a common attribute.                |
|_______________________________________________________________________|
 -->

<!ENTITY % extra-common-attr    ""    >

<!ENTITY % common-attr
"    qualify        CDATA        #IMPLIED
    %extra-common-attr;
    id        ID"
>



<!--....................................................................
|    Attributes associated with Production of paper documents and    |
|    publishing.  The following is an entity declaration that can    |
|    be used to provide attributes useful for describing special    |
|    formatting sometimes required for production of paper        |
|    documents.                            |
 .....................................................................-->

<!ENTITY % wrap-formatting-attrs
"    adjust ( adjust | noadjust )    #IMPLIED
"
>
<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Top-level Book Structure                    |
|                                    |
|    Divisions are used:                        |
|                                    |
|     o for conventional purposes that can be distinguished clearly,    |
|       such as an Introduction or a Summary.            |
|                                    |
|       These should be marked up by providing the appropriate value    |
|       to the "type" attribute of the division element.        |
|                                    |
|     o for general purposes that are specific to the document at    |
|       hand and whose purpose isn't listed in the possible values    |
|       for the type attribute, for example, a division titled    |
|       "Entering Text into an Input Field".                |
|                                    |
|       These should be marked up with the "type" attribute        |
|       defaulted to "general."                    |
|                                    |
|    In those cases where a specific, typically more rigidly        |
|    structured type of division is to be marked up, such as a    |
|    division marked as a "message" division, it is up to the author    |
|    to include the correct type of information within the division.    |
|    In this case, that would mean instances of the structured-    |
|    key-data "message", arranged into a list or other structure.    |
|                                    |
|    Note that the Validating Application can be used to verify    |
|    that document instances fit whatever editorial rules have    |
|    been specified.  For example, it could verify a constraint    |
|    such as "a <division> with type=message must contain at least    |
|    one <message>, and a <message> may appear no where else."    |
|                                    |
|    It is assumed that the processing application may choose to    |
|    override the author-supplied title when the type attribute    |
|    implies a specific title.  Regardless, a title should be    |
|    supplied for every division as the information could be        |
|    processed in an environment with a    different style guide    |
|    than the originating organization - even one in which a title    |
|    isn't specified for the type of division named.            |
|_______________________________________________________________________|
-->


<!ELEMENT osf-book    - -
        ( title, meta?, augmentum?,
          preliminaries?, body, supplements? )
                +( site | i18n-bracket | rev-bracket )
>

<!ATTLIST osf-book
    HyTime        NAME    #FIXED    "doc"    -- conforms to HyTime --
    %common-attr;        #REQUIRED
>

<!ELEMENT body        O O    (%s.body;)    >
<!ELEMENT part        - O    (%s.part;)    >
<!ELEMENT chapter    - O    (%s.chapter;)    >
<!ELEMENT section    - O    (%s.section;)    >
<!ELEMENT division    - O    (%s.division;)    >
<!ELEMENT pdivision    - O    (%s.pdivision;)    >

<!ELEMENT preliminaries    - O    (%s.prelim;)    >
<!ELEMENT preface    - O    (%s.preface;)    >
<!ELEMENT foreword    - O    (%s.foreword;)    >

<!ELEMENT supplements    - O    (%s.supplement;)    >
<!ELEMENT appendix    - O    (%s.appendix;)    >


<!ATTLIST ( preliminaries | body | supplements | preface | foreword | part )
    %common-attr;        #IMPLIED
>
<!ATTLIST ( chapter | section | appendix | division )
    type    ( %division-types; )    #IMPLIED
    %common-attr;        #IMPLIED
>

<!ATTLIST pdivision
    type    ( %pdivision-types; )    #IMPLIED
                    -- the type of prelim division --
    %common-attr;        #IMPLIED
>

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Top-level Refpage Structure                    |
|                                    |
|    Rdivisions are used:                        |
|                                    |
|     o for conventional purposes that can be distinguished clearly,    |
|       such as Purpose or Description.                |
|                                    |
|       These should be marked up by providing the appropriate value    |
|       to the "type" attribute of the rdivision element.        |
|                                    |
|     o for general purposes that are specific to the document at    |
|       hand    and whose purpose isn't listed in the possible values    |
|       for the type attribute, for example, a division titled    |
|       "Entering Text into an Input Field".                |
|                                    |
|    This module, ref-hier.mod, is independent so that it can be    |
|    considered part of the overall OSF book DTD or standalone for    |
|    use with individual manual / reference pages.  Please see the    |
|    module book-hier.mod that defines the <osf-book> and <division>    |
|    tags for how they treat the same issues for a book, and to see    |
|    how reference pages may be integrated into a book.        |
|                                    |
|    It is assumed that the processing application may choose to    |
|    override the author-supplied title when the type attribute    |
|    implies a specific title.  Regardless, a title should be    |
|    supplied for every rdivision as the information could be    |
|    processed in an environment with a different style guide than    |
|    the originating organization - even one in which a title isn't    |
|    specified for the type of division named.            |
|_______________________________________________________________________|
-->


<!ELEMENT osf-refpage    - O
        ( meta?, augmentum?,
          ref-name, ref-purpose, ( sub-name, sub-purpose? )*,
          %s.rbody )
                +( site | i18n-bracket | rev-bracket )
>

<!ATTLIST osf-refpage
    category    CDATA    #IMPLIED
        -- possible values for category: user cmd, admin cmd, net,
           sys call, library call, file, device, statement, markup,
           other --
    HyTime        NAME    #FIXED    "doc"    -- conforms to HyTime --
    %common-attr;        #REQUIRED
>


<!ELEMENT ( ref-name | sub-name )    - O    ( (%s.ttext;)* )    >
<!ELEMENT ( ref-purpose | sub-purpose )    - O    ( (%s.leaf;)* )        >

<!ATTLIST ( ref-name | sub-name | ref-purpose | sub-purpose )
    %common-attr;        #IMPLIED
>

<!ELEMENT rsection    - O    ( %s.rsection; )    >
<!ELEMENT rsubsection    - O    ( %s.rsubsection; )    >
<!ELEMENT rdivision    - O    ( %s.rdivision; )    >

<!ATTLIST rsection
    type    ( %rsection-types; )    #IMPLIED
                    -- the type of section --
    %common-attr;        #IMPLIED
>

<!ATTLIST rsubsection
    type    ( %rsubsection-types; )    #IMPLIED
                    -- the type of subsection --
    %common-attr;        #IMPLIED
>

<!ATTLIST rdivision
    type    ( %rsection-types; | %rsubsection-types; ) #IMPLIED
                    -- the type of rdivision --
    %common-attr;        #IMPLIED
>
<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Meta information                        |
|                                    |
|    Meta information is information about the document or reference    |
|    page that is not (necessarily) included in the document itself.    |
|    The content of the meta information is a long list of various    |
|    elements, mostly optional, that can be used to describe the    |
|    meta information to a fine level of granularity.  Examples    |
|    include "translat-hist" for a description of the translation    |
|    history of the document, and "req-os" "req-software" and    |
|    "req-hardware" to describe the required platform for the    |
|    product being described by the document.            |
|                                    |
|    It is hoped that the current level of fine granularity is    |
|    valuable for the creation of tools that can automatically    |
|    process the meta information.  However, the specific content    |
|    of these sub-elements is generally specified as %s.leaf;,    |
|    and isn't any more specific.  It may turn out that further    |
|    specification of the contents of the sub-elements is required    |
|    to really meet this goal.                    |
|_______________________________________________________________________|
-->


<!ELEMENT meta    - O    ( doc-id?, product-id?, notices?, desc-pool? ) >

<!ATTLIST meta
    %common-attr;        #IMPLIED
>

<!ELEMENT doc-id    - O
        ( manual-type?, collection?, audience?,
          order-id?, isbn?, update-hist?, valid-date?, translat-hist?,
          abstract?, retrieval-keys?, author-info?, doc-version?,
          reviewers?, volume-info? )
>
<!ELEMENT product-id    - O
        ( product+, req-os*, req-software*, req-hardware* )
>
<!ELEMENT notices    - O
        ( disclaimer?, safety?, copyrights?, trademarks?, sw-license?,
          govt-rights?, fcc-warning?, acknowledgements?, misc-notice* )
>

<!ATTLIST doc-id
    draft-status        (draft|review|final)    #IMPLIED
    security-status        (members|open|osfonly)    #IMPLIED
    origin-country        CDATA            #IMPLIED
    origin-language        CDATA            #IMPLIED
    %common-attr;        #IMPLIED
>
<!ATTLIST ( product-id | notices )
    %common-attr;        #IMPLIED
>


<!--....................................................................
.    doc-id contents                            .
 .....................................................................-->

<!ELEMENT manual-type     - O    (%s.text;)*        >
<!ELEMENT collection     - O    (%s.text;)*        >
<!ELEMENT audience     - O    ((%s.leaf;)* | (%s.branch.text;)*)    >
<!ELEMENT order-id     - O    (%s.identifier;)*    >
<!ELEMENT isbn         - O    (%s.identifier;)*    >
<!ELEMENT update-hist     - O    (%s.branch.text;)*    >
<!ELEMENT valid-date     - O    (%s.date;)*        >
<!ELEMENT translat-hist     - O    (%s.branch.text;)*    >
<!ELEMENT abstract     - O    (%s.branch.text;)*    >
<!ELEMENT retrieval-keys - O    (#PCDATA)        >
<!ELEMENT doc-version     - O    (%s.identifier;)*    >
<!ELEMENT reviewers     - O    (%s.branch.text;)*    >
<!ELEMENT volume-info     - O    (%s.text;)*        >

<!ATTLIST ( manual-type | collection | audience | order-id | isbn |
        update-hist | valid-date | translat-hist | abstract |
        retrieval-keys | doc-version | reviewers | volume-info )
    %common-attr;        #IMPLIED
>


<!--....................................................................
.    product-id contents                        .
 .....................................................................-->

<!ELEMENT ( req-os | req-software | req-hardware )    - O
        ( product-name, product-version* )
>

<!ELEMENT ( product )    - O    ( product-name, product-version? )    >

<!ELEMENT ( product-name | product-version)    - O    (%s.text;)*    >

<!ATTLIST ( req-os | req-software | req-hardware |
        product-name | product-version )
    %common-attr;        #IMPLIED
>
<!ATTLIST product
    type        (sw|hw|os|other)    #IMPLIED
    %common-attr;    #IMPLIED
>


<!--....................................................................
.    notices contents                        .
 .....................................................................-->

<!ELEMENT ( disclaimer | safety | sw-license | govt-rights | fcc-warning |
        acknowledgements | misc-notice ) - O
        (%s.branch.text;)*
>
<!ELEMENT copyrights    - O    ( copyright-notice+ )        >
<!ELEMENT copyright-notice - O    ( owner, year+, statement? )    >

<!ATTLIST copyright-notice
    registration    CDATA    #IMPLIED
    %common-attr;        #IMPLIED
>

<!ELEMENT owner        - O    ( #PCDATA | %s.name; )+        >
<!ELEMENT statement    - O    ( #PCDATA | %s.name; | %s.normal; | quote )+    >
<!ELEMENT trademarks    - O    ( trademark-pair+ )        >
<!ELEMENT trademark-pair - O    ( trademark, statement )    >

<!ATTLIST ( disclaimer | safety | sw-license | govt-rights |
        fcc-warning | acknowledgements | copyrights | owner |
        trademarks | trademark-pair | statement )
    %common-attr;        #IMPLIED
>
<!ATTLIST misc-notice
    type        CDATA    #IMPLIED
    %common-attr;        #IMPLIED
>


<!ELEMENT desc-pool    - O
        ( i18n-description*, rev-description* )
>

<!ATTLIST desc-pool
    %common-attr;        #IMPLIED
>
<!--FF-->

<!--
 _______________________________________________________________________
|                                    |
|    augmentum                            |
|                                    |
|    These are common to the document as a whole and to divisions.    |
|    note-pool is declared with the davenport elements.        |
|_______________________________________________________________________|
-->

<!ELEMENT augmentum    - O    ( navigation?, summary?, note-pool? )    >

<!ATTLIST augmentum
    %common-attr;        #IMPLIED
>

<!--....................................................................
.    summary:  document summary (not abstract)            .
 .....................................................................-->

<!ELEMENT summary    - O    ( title, (%s.branch;)* )    >

<!ATTLIST summary
    %common-attr;        #IMPLIED
>


<!--....................................................................
.    navigation:  only the non-HyTime parts                .
 .....................................................................-->

<!ELEMENT navigation    - O
        ( toc*, index*, bibliography*, glossary*, xref-pool*,
        hy-pool* )
>

<!ELEMENT xref-pool    - O    ( xref* )    >
<!ELEMENT hy-pool    - O    ( hy-entry* )    >

<!ATTLIST (navigation | xref-pool | hy-pool )
    %common-attr;        #IMPLIED
>



<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Titles                                |
|                                    |
|    There are two kinds of titles, regular (long) and alternate.    |
|    <title> is the default, regular title.  <alt-title> is for    |
|    contexts where the presentation medium is constrained in size    |
|    or graphical capability.                    |
|                                    |
|    Instead of providing distinct title elements for use in titling    |
|    different elements, we have the generic <title> elements    |
|    which automatically title their immediately containing        |
|    elements. For example, both a <display> and the <section>    |
|    containing a <display> may both contain a <title>, but there    |
|    should be no confusion between the two because of the context    |
|    that the <title> appears in.                    |
|_______________________________________________________________________|
-->

<!ELEMENT title    - -    ( (%s.leaf;)*, alt-title? )    >

<!ELEMENT alt-title - O    ( (%s.text;)* )            >

<!ATTLIST ( title | alt-title )
    %wrap-formatting-attrs;        -- special for production use --
    %common-attr;        #IMPLIED
>

<!ELEMENT bridge-title - O    ( %s.leaf; )    >

<!ATTLIST bridge-title
    HyTime        NAME    ilink
    anchrole    NAMES    #FIXED    "signifier AGG signified AGG"
    reftype        CDATA    #FIXED    "activity dav.policies
                     endterms dav.choiceSignifier.activity"
    activity    IDREFS    #IMPLIED
    linkends    IDREFS    #IMPLIED    -- HyTime calls for REQUIRED --
    extra        NAMES    #IMPLIED
       -- lextype(("E"|"I"|"A"|"N"|"P"), (s+, ("E"|"I"|"A"|"N"|"P"))*) --
    intra        NAMES    #IMPLIED
       -- lextype(("E"|"I"|"A"|"N"|"P"), (s+, ("E"|"I"|"A"|"N"|"P"))*) --
    endterms    IDREFS    #IMPLIED
    aggtrav        NAMES    agg
       -- lextype (("agg"|"mem"|"cor"), (s+, ("agg"|"mem"|"cor"))*) --
    context        (context|ncontext) ncontext
    %wrap-formatting-attrs;        -- special for production use --
    %common-attr;        #IMPLIED  -- (includes id) --
>
<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Paragraphs                            |
|                                    |
|    The American Heritage Dictionary [1982, 1985] states that a    |
|    paragraph is "a distinct division of a written work ... that    |
|    expresses a thought or point relevant to the whole but is    |
|    complete in itself, and may consist of a single sentence or    |
|    several    sentences."                        |
|                                    |
|    Because a sentence may span elements (for example, start in a    |
|    wrapping area, but end in a list), the content model for    |
|    paragraphs includes a variety of other elements.  Other        |
|    have been chosen (see the definition of s.pbranch) based on    |
|    whether they could continue a sentence or not.  For this    |
|    reason, titles, notes, and bridging-titles are excluded from    |
|    the content of a paragraph.                    |
|                                    |
|    Note that the content model of paragraph specifies that a    |
|    paragraph start with (%s.leaf;)+.  Because s.leaf contains    |
|    PCDATA, (%s.leaf;)+ may in practice be empty.  However, the    |
|    intention is that a paragraph start with real content in    |
|    s.leaf because that is where a sentence should start.        |
|    Validating Applications may want to check for real content    |
|    in the initial s.leaf to verify good editorial style.        |
|_______________________________________________________________________|
-->

<!ELEMENT p    - -    ( (%s.leaf;)+, (%s.pbranch;)? )+  -(title)    >

<!ATTLIST p
    %wrap-formatting-attrs;        -- special for production use --
    %common-attr;    #IMPLIED
>

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Key Data                            |
|                                    |
|    Key data markup is used, generally at the "leaves" of a        |
|    document tree, to characterize the semantics of particular    |
|    pieces of text.  This fills the role of OSF's SML "meaningful    |
|    text markup."  This DTD attempts to walk the line between    |
|    defining enough different semantics to be useful and not    |
|    defining so many that it becomes hard to find the right markup.    |
|                                    |
|    There are several types:                    |
|                                    |
|      Technical Key Data    describes technical terms/semantics    |
|                                    |
|      Media Key Data    allows inclusion of alternate        |
|                (non-text) content            |
|                                    |
|      General Key Data    describes general semantics        |
|_______________________________________________________________________|
-->


<!--....................................................................
|    General key data types                        |
 .....................................................................-->

<!ELEMENT (%g.text;)    - O    (#PCDATA)    >

<!ELEMENT (%g.name;)    - O    (#PCDATA)    >

<!ELEMENT (%g.normal;)    - O    (#PCDATA)    >

<!ELEMENT quote        - O    (%s.leaf;)*    -(quote)    >

<!ELEMENT number    - O    (#PCDATA)    >

<!ELEMENT msg-number    - O    (#PCDATA)    >

<!ATTLIST (%g.text;)
    %common-attr;        #IMPLIED
>
<!ATTLIST (%g.name;)
    %common-attr;        #IMPLIED
>
<!ATTLIST (%g.normal;)
    normalized    CDATA    #IMPLIED
            --  normalized values: date: ISO date, time: GMT,
                telephone: include +country code, year: Gregorian,
                e-mail: internet --
    %common-attr;        #IMPLIED
>
<!ATTLIST quote
    %common-attr;        #IMPLIED
>

<!ATTLIST number
    radix            (decimal|binary|octal|hex)    #IMPLIED
    unit-of-measure        CDATA    #IMPLIED
    %common-attr;        #IMPLIED
>
<!ATTLIST msg-number
    %common-attr;        #IMPLIED
>

<!--....................................................................
|    Some "special" elements (grouped as g.special).            |
|    different-lang is similar to g.name, but has different        |
|    attributes.                            |
 .....................................................................-->

<!ELEMENT (different-lang | calendar-ref)    - O    (#PCDATA)    >
<!ATTLIST (different-lang | calendar-ref)
    locale        CDATA    #IMPLIED
    %common-attr;        #IMPLIED
>

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Technical Key Data                        |
|_______________________________________________________________________|
-->

<!ELEMENT input-instruct - O    (%s.text)*    >

<!ELEMENT msg-text    - O    (%s.text)*    >

<!ELEMENT (%g.tname;)    - O    (#PCDATA)    >

<!ELEMENT (%g.io;)    - O    (#PCDATA)    >

<!ELEMENT logical-negation - O    (#PCDATA)    >


<!--....................................................................
|    Some "special" elements (grouped as g.tspecial).        |
|    option-name and misc-data are similar to g.tname,        |
|    but have different attributes                    |
 .....................................................................-->

<!ELEMENT option-name    - O    (#PCDATA)    >

<!ELEMENT misc-data    - O    (#PCDATA)    >

<!ELEMENT markup    - O    (#PCDATA)    >


<!ATTLIST (input-instruct | msg-text | logical-negation)
    %common-attr;        #IMPLIED
>
<!ATTLIST (%g.tname;)
    %common-attr;        #IMPLIED
>


<!ATTLIST (%g.io;)
    %common-attr;        #IMPLIED
>

<!ATTLIST option-name
    presence    ( optional | required )    #IMPLIED
    %common-attr;        #IMPLIED
>
<!ATTLIST misc-data
    desc        CDATA    #REQUIRED
        -- holds a description of this otherwise unknown key data --
    %common-attr;        #IMPLIED
>
<!ATTLIST markup
    lang        CDATA    #IMPLIED    -- expected values are sgml,
                           troff, or TeX --
    category    CDATA    #IMPLIED    -- elem, att, macro,
                           control-seq, etc. --
    %common-attr;        #IMPLIED
>
<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Media key data types                        |
|_______________________________________________________________________|
-->

<!--....................................................................
|    Static graphics                            |
 .....................................................................-->

<!ELEMENT graphic    - O    RCDATA    >

<!ATTLIST graphic
    notation NOTATION    ( eps | spdl | cgm | ccitt4 )    eps
    name     ENTITY        #CONREF
    %common-attr;        #IMPLIED
>

<!NOTATION eps        SYSTEM    ""    >
<!NOTATION spdl        SYSTEM    ""    -- use EPS until SPDL is available -- >
<!NOTATION cgm        SYSTEM    ""    >
<!NOTATION ccitt4    SYSTEM    ""    >

<!ATTLIST #NOTATION ( spdl | cgm | ccitt4 )
    width        CDATA    #IMPLIED
    height        CDATA    #IMPLIED
    scale        CDATA    #IMPLIED
    orientation    (portrait|landscape)    #IMPLIED
>

<!--....................................................................
|    Audio data.  It does not really matter what formats are listed    |
|    since OSF documents will not have audio data for a long time,    |
|    if ever.                            |
 .....................................................................-->

<!ELEMENT audio    - O    RCDATA    >

<!ATTLIST audio
    notation NOTATION    (u-law|aiff|riff)    u-law
    name     ENTITY        #CONREF
    %common-attr;        #IMPLIED
>

<!NOTATION u-law    SYSTEM    ""    >
<!NOTATION aiff        SYSTEM    ""    >
<!NOTATION riff        SYSTEM    ""    >

<!--....................................................................
|    Video data.  It does not really matter what formats are listed    |
|    since OSF documents will not have video data for a long time,    |
|    if ever.                            |
 .....................................................................-->

<!ELEMENT video    - O    RCDATA        >

<!ATTLIST video
    notation NOTATION    (pal|ntsc)    ntsc
    name     ENTITY        #CONREF
    %common-attr;        #IMPLIED
>

<!NOTATION ntsc        SYSTEM    ""    >
<!NOTATION pal        SYSTEM    ""    >

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Structured Key Data                        |
|                                    |
|    Structured key data, as its name implies, is basically a    |
|    collection of atomic information (some of it is key data in    |
|    its own right) that is put together into a larger structure    |
|    (similar to a C language structure).                |
|                                    |
|    Here, we describe the top-level key data, then flesh it out    |
|    with inner element content.  For example, we declare the    |
|    <message> element, then define its content model as a set of    |
|    contained sub-elements (rather than saying that its content    |
|    model is just #PCDATA).                        |
|                                    |
|    The sub-elements that make up a structured key data need not be    |
|    available in any context other than the structured key data    |
|    itself.  On the other hand, key data structures often appear as    |
|    content    models for other GIs (such as lists).            |
|_______________________________________________________________________|
-->

<!ELEMENT message    - O
    ( ((product?, msg-code, msg-symbol?, msg-text*)+ | msg-text+),
      (msg-type?, msg-desc*, msg-cause?, (msg-audience?, msg-resp)*,
       msg-origin*)? )

>
<!ELEMENT (msg-code | msg-symbol | msg-type | msg-audience | msg-origin) - O
        (%s.leaf;)*
>
<!ELEMENT (msg-desc | msg-cause | msg-resp)    - O
        (%s.everything;)
>

<!ATTLIST message
    %common-attr;            #IMPLIED
>
<!ATTLIST (msg-code | msg-symbol | msg-type | msg-audience | msg-origin |
        msg-desc | msg-cause | msg-resp)
    %common-attr;            #IMPLIED
>
<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    These are miscellaneous "smaller" structured things.        |
|_______________________________________________________________________|
-->

<!ELEMENT author-info    - O    ( person | auth-affiliation | address )+ >
<!ELEMENT auth-affiliation - O    (%s.text;)*    >

<!ATTLIST ( author-info | auth-affiliation )
    %common-attr;        #IMPLIED
>


<!ELEMENT address - O    (#PCDATA)    -- RCDATA or RDATA? --    >

<!ATTLIST address
    %common-attr;        #IMPLIED
>


<!ELEMENT excerpt - O    (%s.branch;)*    >

<!ATTLIST excerpt
    source            CDATA        #IMPLIED
    %common-attr;        #IMPLIED
>

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    There are three types of synopses:                |
|                                    |
|    proglang-synopsis  for describing structured programming    |
|            language (eg, C) functions, declarations,    |
|            and data structures                |
|                                    |
|    cmd-synopsis    for describing command language commands    |
|            (eg, command available from a UNIX shell)    |
|                                    |
|    file-synopsis    for describing file formats/contents        |
|            (eg, /etc/passwd)                |
|                                    |
|    Each offers a content model intended to fairly closely fit    |
|    its target content, though proglang-synopsis is not as rigorous    |
|    as the programming languages that it hopes to support.  There    |
|    is hope that, eventually, programming code may be included    |
|    in a document verbatim, and that lexical analysis can        |
|    automatically produce more accurate markup semantics without    |
|    forcing the writer to understand both C and its SGML analog.    |
|                                    |
|    Subelements of these synopses (viz, cmd-argument and        |
|    data-declaration) have been coded for general use, such as    |
|    when an option is being discussed in text away from the        |
|    "official" synopsis.  This is why cmd-argument and        |
|    data-declaration are available within s.leaf and s.ttext.    |
|_______________________________________________________________________|
-->



<!--....................................................................
|    proglang-synopsis describes how a function is called        |
 .....................................................................-->

<!ELEMENT proglang-synopsis    - O
        ( include*,
          data-declaration*,
          ( datatype?, function, data-declaration* )? )
                    -- optional function declaration --
>
<!ATTLIST proglang-synopsis
    lang        CDATA        #IMPLIED
    type  (function|data-structure)    #REQUIRED
    %common-attr;            #IMPLIED
>

<!ELEMENT data-declaration    - O
        ( datatype?, ( variable | number | literal )* )
>
<!ATTLIST data-declaration
    %common-attr;        #IMPLIED
>

<!ELEMENT include    - O    (%s.filename;)*        >

<!ATTLIST include
    %common-attr;        #IMPLIED
>



<!--....................................................................
|    return-code describes what a function can return        |
 .....................................................................-->

<!ELEMENT return-code - O
        ( product?, code-number, code-mnemonic*, code-desc )
>
<!ELEMENT code-number - O    ( #PCDATA )        >
<!ELEMENT code-mnemonic - O    (%s.leaf;)*        >
<!ELEMENT code-desc - O        ( (%s.everything;) )    >

<!ATTLIST ( return-code | code-number | code-mnemonic | code-desc )
    %common-attr;        #IMPLIED
>
<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Command synopsis                        |
|                                    |
|    The following markup is a general solution to command synopses    |
|    of the kind typically found in the SYNOPSIS section of a    |
|    reference page.                            |
|                                    |
|    These markups are deceptively simple, but should provide the    |
|    ability to mark up the variety of OSF command lines.        |
|                                    |
|    Some examples of how this markup should be used:        |
|                                    |
|        make [ -f file ]                    |
|                                    |
|            <cmd-synopsis>                    |
|              <command>make</>                |
|              <cmd-argument optional separator=" ">        |
|                <option-name>-f</>                |
|                <variable>file</>                |
|            </></>                        |
|                                    |
|        cpio -o [aBcv] [-C value] [-M "string"]    file ...    |
|                                    |
|            <cmd-synopsis>                    |
|              <command>cpio</>                |
|              <cmd-argument iff anyorder>            |
|                <option-name>-o</>                |
|                <cmd-argument optional>            |
|                  <option-name>a</>                |
|                  <option-name>B</>                |
|                  <option-name>c</>                |
|                  <option-name>v</>                |
|                </>                        |
|                <cmd-argument optional separator=" ">    |
|                  <option-name>-C</>            |
|                  <variable>value</>            |
|                </>                        |
|                <cmd-argument optional separator=" ">    |
|                  <option-name>-M</>            |
|                  <variable>"string"</>            |
|                </>                        |
|                <cmd-argument repeatable>            |
|                  <variable>file</>                |
|            </></></>                    |
|                                    |
|    Note that there are other forms of the cpio command based on    |
|    the first argument.                        |
|                                    |
|_______________________________________________________________________|
-->

<!--....................................................................
|    cmd-synopsis is generally a name followed by arguments, though    |
|    there is the option for allowing content before the command    |
|    name                                |
 .....................................................................-->

<!ELEMENT cmd-synopsis    - O
            ( cmd-argument*, command, cmd-argument* )    >

<!ATTLIST cmd-synopsis
    %common-attr;          #IMPLIED
>

<!--....................................................................
|    cmd-argument is a group of options and/or other arguments    |
 .....................................................................-->

<!ELEMENT cmd-argument    - O    ( option-name | variable | literal |
                            cmd-argument )*    >

<!ATTLIST cmd-argument

    type    ( iff | or | group )    #IMPLIED
            -- what kind of group is this?
               iff     if the first child is present, use the rest
               or      pick one of the children
               group   implicit and (default) --

    separator    CDATA              #IMPLIED
                    -- separator between children --

    repeatability    ( repeatable | unique )    #IMPLIED
                    -- repeat all children --

    presence    ( optional | required )    #IMPLIED

    order        ( anyorder | ordered )    #IMPLIED
                    -- children in any order --

    %common-attr;          #IMPLIED
>
<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    File synopsis                            |
|                                    |
|    The file synopsis is used, generally in reference pages,    |
|    to name a path/filename to be discussed.  Note that the        |
|    elements "path" and "file" are also available for use in    |
|    text areas, but that file-synopsis should be used in the    |
|    synopsis section of a reference page.                |
|                                    |
|_______________________________________________________________________|
-->


<!ELEMENT file-synopsis    - O    ( ( %s.tleaf; )* )    >

<!ATTLIST file-synopsis
    %common-attr;          #IMPLIED
>

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Notes                                |
|                                    |
|    Notes are very similar to displays, except that they indicate    |
|    semantics explicitly via attributes.  These notes are generally    |
|    intended to be processed within the linear flow of text (as    |
|    opposed    to annotations).  The most common use is to make an    |
|    emphasized presentation of content to a reader.            |
|_______________________________________________________________________|
-->

<!ELEMENT note    - O    ( title?, (%s.branch;)* )    -(note)    >

<!ATTLIST note
        type    ( caution | warning | danger | qualified | reviewer |
              general | side )    #REQUIRED
        %common-attr;        #IMPLIED
>
<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Lists                                |
|                                    |
|    A list is a sequence of uniform items, generally with a single    |
|    (type of) "mark" that indicates the beginning of a new item,    |
|    followed by the body of the item.  In some types of lists, the    |
|    mark can vary from item    to item.  Some types of lists are    |
|    specialized to contain a consistent set of structured key data    |
|    (eg, messages).                            |
|                                    |
|    The various types of lists are designed as specific content    |
|    model choices under the generic identifier "list."  This allows    |
|    all lists to be seen as lists and provides a convenient method    |
|    of creating the various specific types of lists without having    |
|    to remember different list tags.                |
|                                    |
|    "Introductory" and/or "in-between" paragraphs are allowed    |
|    within a list.                            |
|_______________________________________________________________________|
-->

<!ELEMENT list    - -
        ( ( item, ( item | bridge-p )* )    |
            ( l-item, ( l-item | bridge-p )* )    |
            message+                |
            note+                |
            ( procedure-step, ( procedure-step | bridge-p )* ) )
>

<!ATTLIST list
    type    ( ordered | unordered )    #IMPLIED
        -- this governs whether items in the list should be
           automatically and uniquely labeled --
    marks    ( adorned | unadorned )    #IMPLIED
        -- unadorned prevents all generated marks from appearing --
    %common-attr;        #IMPLIED
>

<!ELEMENT ( item | procedure-step )    - O    ( (%s.everything;) )    >

<!ELEMENT l-item    - O    ( label, item )        >

<!ELEMENT label        - O    (%s.leaf;)*        >

<!ATTLIST ( item | l-item | label | procedure-step )
    %common-attr;        #IMPLIED
>


<!--....................................................................
|    A "bridging paragraph".  Allowed only between (some) list    |
|    items.  This is basically an ilink, but by default, the places    |
|    pointed to are the immediately preceding and following items.    |
 .....................................................................-->

<!ELEMENT bridge-p    - O    ( %s.leaf; )*    >

<!ATTLIST bridge-p
    HyTime        NAME    ilink
    id        ID    #IMPLIED
    anchrole    NAMES    #FIXED    "signifier AGG signified AGG"
    reftype        CDATA    #FIXED    "activity dav.policies
                     endterms dav.choiceSignifier.activity"
    activity    IDREFS    #IMPLIED
    linkends    IDREFS    #IMPLIED    -- HyTime calls for REQUIRED --
    extra        NAMES    #IMPLIED
       -- lextype(("E"|"I"|"A"|"N"|"P"), (s+, ("E"|"I"|"A"|"N"|"P"))*) --
    intra        NAMES    #IMPLIED
       -- lextype(("E"|"I"|"A"|"N"|"P"), (s+, ("E"|"I"|"A"|"N"|"P"))*) --
    endterms    IDREFS    #IMPLIED
    aggtrav        NAMES    agg
       -- lextype (("agg"|"mem"|"cor"), (s+, ("agg"|"mem"|"cor"))*) --
    context        (context|ncontext) ncontext
>

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|   Tables                                |
|                                    |
|    A table is composed of rows, which are composed of cells.    |
|    A title-row looks and acts very much like a row, but is used    |
|    for column titles/headings, whether at the top of the table    |
|    or sprinkled throughout.                    |
|                                    |
|    A "model" is an author-supplied descriptor for the type of    |
|    information contained in each column.  It is written in a    |
|    pseudo-SGML language and is intended both for verification of    |
|    cell content (with an application or by hand) and as a hint    |
|    to those who may edit the table.  It is *not* intended to    |
|    be automatically applied by a formatting application.  The    |
|    syntax of values for a model is:                |
|        model="type1,type2,type3,..."                |
|                                    |
|    where the number of type's exactly matches the number of    |
|    columns's in each row of the table.  A type may have the    |
|    values:                                |
|                                    |
|        VALUE    MEANING                        |
|        <tag>    a valid SGML OSF DTD tag with which to treat    |
|            the content of each corresponding cell.        |
|        text    the cell contains arbitrary text        |
|                                    |
|    Each row may override the table's model (for that cell        |
|    alone) by providing a model attribute.  The syntax of a        |
|    model is identical to that of a table's model except that it    |
|    also allows the following values:                |
|                                    |
|        span    content in the previous cell (same row) should    |
|            span across this column                |
|        vspan    content in the same cell in the previous row    |
|            should span (downwards) into this cell.        |
|                                    |
|    The ability to set a model for the entire table, but override    |
|    it as necessary for a particular row allows for the description    |
|    of complicated tables.                        |
|                                    |
|    Other attributes:                        |
|                                    |
|    "ncols" is the expected number of columns in the table        |
|    "colwidth" is a list of the width of each column        |
|    "colweight" is a list of the weights of the columns, expressed    |
|        as proportion of the table alloted to each column.        |
|    "halign", "valign" are lists of how the content of each cell    |
|        will be aligned (top, bottom, center, left, right)        |
|    "colsep", "rowsep" are lists of separator characters to be    |
|        used between the cells (bars, lines, dots, etc.)        |
|    "wrap" is a list of hints about how to wrap text that is too    |
|        wide for cells                        |
|                                    |
|    Values may be specified for the entire table, for each row,    |
|    or an individual cell.  The latter are meant to be used as    |
|    overrides to values set for the entire table.            |
|                                    |
|_______________________________________________________________________|
-->

<!ELEMENT table        - O    ( title-row | row )*    >

<!ATTLIST table
    ncols        NUMBER     #IMPLIED -- num of cells/row should match --
    model        CDATA     #IMPLIED -- column prototypes for this table --
    colwidth    NUTOKENS #IMPLIED -- absolute widths of cols --
    colweight    NUMBERS     #IMPLIED -- column weights --
    halign        CDATA     #IMPLIED -- horiz alignment for columns --
    valign        CDATA     #IMPLIED -- vertical alignment for columns --
    colsep        CDATA     #IMPLIED -- use col separators (lines)? --
    rowsep        CDATA     #IMPLIED -- use row separators (lines)? --
    wrap        CDATA     #IMPLIED -- wrap hints for columns --
    %common-attr;         #IMPLIED
>

<!ELEMENT ( title-row | row )    - O    ( cell* )    >

<!ATTLIST ( title-row | row )
    model        CDATA     #IMPLIED -- model override for this row --
    colwidth    NUTOKENS #IMPLIED -- abs widths of cols --
    colweight    NUMBERS     #IMPLIED -- column weights --
    halign        CDATA     #IMPLIED -- horiz alignment for columns --
    valign        CDATA     #IMPLIED -- vertical alignment for columns --
    colsep        CDATA     #IMPLIED -- use col separators (lines)? --
    rowsep        CDATA     #IMPLIED -- use row separators (lines)? --
    wrap        CDATA     #IMPLIED -- wrap hints for columns --
    %common-attr;         #IMPLIED
>

<!ELEMENT cell        - O    ( (%s.leaf;)* | p* )    >

<!ATTLIST cell
    model        CDATA    #IMPLIED -- model override for this cell --
    halign        CDATA    #IMPLIED -- horiz alignment for cell --
    valign        CDATA    #IMPLIED -- vertical alignment for cell --
    colsep        CDATA    #IMPLIED -- use col separators (lines)? --
    rowsep        CDATA    #IMPLIED -- use row separators (lines)? --
    wrap        CDATA    #IMPLIED -- wrap hints for cell --
    %common-attr;        #IMPLIED
>

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Displays                            |
|                                    |
|    A display is an "atomic" chunk of material that is intended    |
|    to be presented as a figure, example, etc.  Instead of        |
|    representing a specific semantic by itself, a display is just    |
|    a container - it is the content that holds the semantic.    |
|                                    |
|    A display *is* expected to be represented by some appearance    |
|    that visually distinguishes it from before and after content.    |
|    As such, what otherwise might have been one tag for inline    |
|    key data and a different one for the "standalone" case is    |
|    instead handled using the same key data markup either outside    |
|    of or inside of (respectively) a display.            |
|                                    |
|    There is a display attribute to specify whether the display    |
|    must remain at that specific point within the surrounding    |
|    content (ie, a static display), or whether it may "move" to    |
|    nearby places (ie, a floating display).                |
|                                    |
|    Although, in other markup systems, this might be the place to    |
|    specify appearance specific information (indentation, allowed    |
|    page breaking, etc), this is held to an absolute minimum here.    |
|    Applications may consider the content of displays in making    |
|    specific processing decisions.                    |
|_______________________________________________________________________|
-->

<!ELEMENT display    - -    ( title?, (%s.display;) )  -(display)    >

<!ATTLIST display
    in-flow    ( float | static )    #IMPLIED  -- floating or static --
    keep    ( keep | nokeep )    #IMPLIED  -- don't break over page
                             boundry (keep) or allow --
    wrap    ( wrap | nowrap )    #IMPLIED  -- wrap text, or not --
    type    ( general | dialog | example | figure | table | equation )
                    #IMPLIED
    %common-attr;            #IMPLIED
>

<!ELEMENT text-as-figure  - -    RCDATA    -- text used as a figure -- >

<!ELEMENT text-alternate  - O    ( %s.everything; )
                    -- text substitute for a figure --
>

<!ATTLIST (text-as-figure | text-alternate)
    %common-attr;            #IMPLIED
>


<!--FF-->
<!--
_________________________________________________________________________
|                                    |
|    Mathematical Equations and Formulae                |
|_______________________________________________________________________|
-->

<!ELEMENT equation    - O    RCDATA    >

<!ATTLIST equation
    notation NOTATION    (tex)    tex
    name     ENTITY        #CONREF
    %common-attr;        #IMPLIED
>

<!NOTATION tex    SYSTEM    ""    >

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Annotation bodies (includes footnotes)                |
|                                    |
|    Annotations are pieces of supplemental (non-integral)        |
|    information that are "attached to" a particular place in a    |
|    document instance, but are not necessarily intended to be    |
|    represented at that point itself.  Examples are footnotes and    |
|    review comments.                        |
|                                    |
|    These markups are intended to be connected to specific places    |
|    in documents by specifying the ID of the specific place with    |
|    the anchor attribute.  If the referred-to place doesn't        |
|    already have an ID, then a site markup can be used there to    |
|    provide that ID.                        |
|                                    |
|    Although the standard method of connecting an annotation/    |
|    footnote body to a referred-to place is via standard SGML IDs    |
|    and IDREFs, HyTime location and linking primitives may be used    |
|    to increase the power and addressing range of the connections.    |
|_______________________________________________________________________|
-->

<!ELEMENT annotation    - -    (%s.branch;)*    -(annotation)    >

<!ATTLIST annotation
    anchor        IDREF    #REQUIRED
    %common-attr;        #IMPLIED
>


<!ELEMENT footnote    - -    (%s.branch;)*        >

<!ATTLIST footnote
    anchor        IDREF    #REQUIRED
    %common-attr;        #IMPLIED
>

<!--FF-->

<!--
 _______________________________________________________________________
|                                    |
|    Hyper-Connections, Non-Linear Traversal                |
|                                    |
|                                    |
|    This module defines:                        |
|                                    |
|        glossaries                        |
|        indexes                            |
|        bibliographies                        |
|        tables of contents                    |
|        cross references                    |
|                                    |
|    These features are implemented in conformance with the        |
|    Davenport Advisory Specification for Hypermedia (DASH), circa    |
|    October 5, 1992.                        |
|                                    |
|    Here's a brief explanation of how this stuff is intended to    |
|    be used:                            |
|                                    |
|      <site>    marks up "interesting" content in a document.    |
|            ie, a place that might be indexed, cross    |
|            referenced, associated with a glossary entry,    |
|            etc.                        |
|                                    |
|      <hy-locator>    names a collection of <site>'s (each of which    |
|            are presumably the same uses of the same term).    |
|                                    |
|      <hy-sign>    describes a piece of information, and is made    |
|            up of two parts:  a name (hy-term) and a    |
|            definition (hy-def).  This constitutes a "meta"    |
|            definition, in that it isn't itself expected    |
|            to be used within a document.            |
|                                    |
|      <hy-term>    holds the name part of a <hy-sign>        |
|                                    |
|      <hy-def>    holds the definition part of a <hy-sign>, ie,    |
|            the def associated with the <hy-term> related    |
|            by the common <hy-sign>.  It may also contain    |
|            child <hy-sign>'s that refine the definition    |
|            via other terms and definitions.        |
|                                    |
|      <hy-entry>    a link that connects a <hy-locator> (ie, a set    |
|            of <site>'s) with a <hy-sign> (ie, the meta    |
|            description of some information).  This        |
|            constitutes an entry in some list of        |
|            information, but we don't know what kind of    |
|            list until the <hy-entry> is actually used.    |
|                                    |
|      <index>    These tags contain lists of <hy-entry>'s.  So,    |
|      <glossary>    an <index> tag contains a list of <hy-entry>    |
|      <bibliography> links that constitute an index.  <hy-entry>    |
|      <toc>        links may appear in more than one of these    |
|            tag's lists.  The order that <hy-entry> links    |
|            appear within one of these tags is generally    |
|            not important (but is for TOC's).        |
|                                    |
|      <xref>    A general cross reference link that connects    |
|            two pieces of content.  May be used to "pull"    |
|            text from one place to the other place, provide    |
|            a general hyper-link between places, or simply    |
|            to state that the places are related somehow.    |
|                                    |
|    Note:  the sgmls parser won't take an anchrole attribute #FIXED    |
|           value that includes "#AGG", so we've left the "#" out..    |
|_______________________________________________________________________|
-->


<!--....................................................................
|    site:  an "in-situ" markup that describes an interesting place.    |
|    This is a key data                         |
 .....................................................................-->

<!ELEMENT site    - O    ( (%s.leaf;)*, note-pool? )    >

<!ATTLIST site         -- Davenport: site of important content --
    Davnport    NAME    #FIXED    "siteloc"
    %common-attr;        #REQUIRED

    -- qualify the term within this site --
    primary        CDATA    #IMPLIED
    secondary    CDATA    #IMPLIED
    tertiary    CDATA    #IMPLIED

    -- some "davenport shortcuts" - temp measures for implementation -
       setting these attribute to the first token causes the term to
       be added to the respective thing (the no* token is the default --
    bibentry    (bibentry|nobibentry)        #IMPLIED
    indexentry    (indexentry|noindexentry)    #IMPLIED
    glossentry    (glossentry|noglossentry)    #IMPLIED

    -- some extra details for index items: --
    see        CDATA    #IMPLIED  -- see other term instead --
    seealso        CDATA    #IMPLIED  -- see other term also --
    emph    (emph|noemph)    #IMPLIED  -- emphasize this entry --
>

<!ELEMENT note-pool    - O    (footnote|annotation)*    >

<!ATTLIST note-pool
    %common-attr;        #IMPLIED
>


<!--....................................................................
|    hy-sign describes a signifier and a signified (a hy-term    |
|    and a hy-def)                            |
 .....................................................................-->

<!ELEMENT hy-sign - O    ( hy-term, hy-def+ )*    >

<!ATTLIST hy-sign
    Davnport    CDATA    "dav.sign.ilink"
    HyTime        NAME    ilink
    id        ID    #IMPLIED
    anchrole    NAMES    #FIXED    "signifier AGG signified AGG"
    reftype        CDATA    #FIXED    "activity dav.policies
                     endterms dav.choiceSignifier.activity"
    activity    IDREFS    #IMPLIED
    linkends    IDREFS    #IMPLIED    -- FLD changed this from IMPLIED - is this correct??? --
    extra        NAMES    #IMPLIED
       -- lextype(("E"|"I"|"A"|"N"|"P"), (s+, ("E"|"I"|"A"|"N"|"P"))*) --
    intra        NAMES    #IMPLIED
       -- lextype(("E"|"I"|"A"|"N"|"P"), (s+, ("E"|"I"|"A"|"N"|"P"))*) --
    endterms    IDREFS    #IMPLIED
    aggtrav        NAMES    agg
       -- lextype (("agg"|"mem"|"cor"), (s+, ("agg"|"mem"|"cor"))*) --
    context        (context|ncontext) ncontext
>


<!--....................................................................
|    hy-term specifies the name of something                |
 .....................................................................-->

<!ELEMENT hy-term - O    (%s.leaf;)*    >

<!ATTLIST hy-term
    Davnport    CDATA    "dav.signifier.HyBrid"
    HyTime        NAME    HyBrid
    id        ID    #IMPLIED
    reftype        CDATA    #FIXED    "activity dav.policies"
    activity    IDREFS    #IMPLIED
    conloc        IDREFS    #CONREF
>


<!--....................................................................
|    hy-def specifies the semantics behind a hy-term, or provides a    |
|    refinement for a hy-sign                    |
 .....................................................................-->

<!ELEMENT hy-def - O    ( hy-sign | ((%s.branch;)* | (%s.leaf;)*) )*    >

<!ATTLIST hy-def
    Davnport    CDATA    "dav.signified.HyBrid"
    HyTime        NAME    HyBrid
    id        ID    #IMPLIED
    reftype        CDATA    #FIXED    "activity dav.policies"
    activity    IDREFS    #IMPLIED
    conloc        IDREFS    #CONREF
>


<!--....................................................................
|    hy-locator names a list of uses of something            |
 .....................................................................-->

<!ELEMENT hy-locator - O    ( hy-nmlist | hy-nmquery )+    >

<!ATTLIST hy-locator
    Davnport    CDATA    "dav.locator.nameloc"
    HyTime        NAME    nameloc
    id        ID    #REQUIRED
    ordering    (ordered|noorder)    noorder
    set        (set|noset)        set
    aggloc        (aggloc|agglink|nagg)    agglink
    reftype        CDATA    #FIXED    "activity dav.policies"
    activity    IDREFS    #IMPLIED
    conloc        IDREFS    #CONREF
>


<!--....................................................................
|    hy-nmlist:  a HyTime name list                    |
 .....................................................................-->

<!ELEMENT hy-nmlist - O    ( #PCDATA )    >

<!ATTLIST hy-nmlist
    HyTime        NAME    nameloc
    role        CDATA    #FIXED    "location-names"
    id        ID    #REQUIRED
    ordering    (ordered|noorder)    noorder
    set        (set|noset)        set
    aggloc        (aggloc|agglink|nagg)    agglink
    reftype        CDATA    #FIXED    "activity dav.policies"
    activity    IDREFS    #IMPLIED
    conloc        IDREFS    #CONREF

    range    (yes|no)    #IMPLIED    -- is this a list or a range? --
    use    (defining|general) #IMPLIED    -- a defining or general use? --
>


<!--....................................................................
|    hy-nmquery:  a HyTime name query, not used now            |
 .....................................................................-->

<!ELEMENT hy-nmquery - O    ( #PCDATA )    >

<!ATTLIST hy-nmquery
    Davnport    CDATA    "dav.nmquery.nmquery"
    HyTime        NAME    nmquery
    id        ID    #IMPLIED    -- default: none --
                -- query attributes --
                -- function attributes --
>


<!--....................................................................
|    hy-entry: a link between a hy-sign and a hy-locator;        |
|    constitutes an entry in something (eg, index)            |
 .....................................................................-->

<!ELEMENT hy-entry - O    ((hy-term | hy-sign)*, hy-locator)?    >

<!ATTLIST hy-entry
    Davnport    CDATA    "dav.entryLink.ilink"
    HyTime        NAME    ilink
    id        ID    #IMPLIED
    anchrole    NAMES    #FIXED    "hy-sign AGG hy-locator AGG"
    reftype        CDATA    #FIXED    "activity dav.policies
                     endterms dav.choiceSignifier.activity"
    activity    IDREFS    #IMPLIED
    linkends    IDREFS    #IMPLIED    -- FLD changed this from IMPLIED - is this correct??? --
    extra        NAMES    #IMPLIED
       -- lextype(("E"|"I"|"A"|"N"|"P"), (s+, ("E"|"I"|"A"|"N"|"P"))*) --
    intra        NAMES    #IMPLIED
       -- lextype(("E"|"I"|"A"|"N"|"P"), (s+, ("E"|"I"|"A"|"N"|"P"))*) --
    endterms    IDREFS    #IMPLIED
    aggtrav        NAMES    agg
       -- lextype (("agg"|"mem"|"cor"), (s+, ("agg"|"mem"|"cor"))*) --
    context        (context|ncontext) ncontext
>


<!--....................................................................
|    glossary:  a collection of hy-entry's that constitute a        |
|    glossary                            |
 .....................................................................-->

<!ELEMENT glossary - O    ( hy-nmlist | hy-nmquery)+    >

<!ATTLIST glossary
    Davnport    CDATA    "dav.collector.nameloc"
    HyTime        NAME    nameloc
    role        CDATA    #FIXED    "glossary"
    id        ID    #REQUIRED
    ordering    (ordered|noorder)    noorder
    set        (set|noset)        set
    aggloc        (aggloc|agglink|nagg)    agglink
    reftype        CDATA    #FIXED    "activity dav.policies"
    activity    IDREFS    #IMPLIED
    conloc        IDREFS    #CONREF
>


<!--....................................................................
|    index:  a collection of hy-entry's that constitute a index    |
 .....................................................................-->

<!ELEMENT index - O    ( hy-nmlist | hy-nmquery)+    >

<!ATTLIST index
    Davnport    CDATA    "dav.collector.nameloc"
    HyTime        NAME    nameloc
    role        CDATA    #FIXED    "index"
    id        ID    #REQUIRED
    ordering    (ordered|noorder)    noorder
    set        (set|noset)        set
    aggloc        (aggloc|agglink|nagg)    agglink
    reftype        CDATA    #FIXED    "activity dav.policies"
    activity    IDREFS    #IMPLIED
    conloc        IDREFS    #CONREF
>


<!--....................................................................
|    toc:  a collection of hy-entry's that constitute a toc        |
 .....................................................................-->

<!ELEMENT toc - O    ( hy-nmlist | hy-nmquery)+    >

<!ATTLIST toc
    Davnport    CDATA    "dav.collector.nameloc"
    HyTime        NAME    nameloc
    role        CDATA    #FIXED    "toc"
    id        ID    #REQUIRED
    ordering    (ordered|noorder)    noorder
    set        (set|noset)        set
    aggloc        (aggloc|agglink|nagg)    agglink
    reftype        CDATA    #FIXED    "activity dav.policies"
    activity    IDREFS    #IMPLIED
    conloc        IDREFS    #CONREF
>


<!--....................................................................
|    bibliography:   a collection of hy-entry's that constitute a    |
|    bibliography                            |
 .....................................................................-->

<!ELEMENT bibliography - O    ( hy-nmlist | hy-nmquery)+    >

<!ATTLIST bibliography
    Davnport    CDATA    "dav.collector.nameloc"
    HyTime        NAME    nameloc
    role        CDATA    #FIXED    "bibliography"
    id        ID    #REQUIRED
    ordering    (ordered|noorder)    noorder
    set        (set|noset)        set
    aggloc        (aggloc|agglink|nagg)    agglink
    reftype        CDATA    #FIXED    "activity dav.policies"
    activity    IDREFS    #IMPLIED
    conloc        IDREFS    #CONREF
>


<!--....................................................................
|    xref:  a general cross-reference                |
 .....................................................................-->

<!ELEMENT xref - O    EMPTY    >

<!ATTLIST xref
    Davnport    CDATA    "dav.xrefLink.ilink"
    HyTime        NAME    ilink
    id        ID    #IMPLIED
    anchrole    NAMES    #FIXED    "refmark AGG refsub AGG"
    reftype        CDATA    #FIXED    "activity dav.policies
                     endterms dav.choiceSignifier.activity"
    activity    IDREFS    #IMPLIED
    linkends    IDREFS    #REQUIRED
    extra        NAMES    #IMPLIED
       -- lextype(("E"|"I"|"A"|"N"|"P"), (s+, ("E"|"I"|"A"|"N"|"P"))*) --
    intra        NAMES    #IMPLIED
       -- lextype(("E"|"I"|"A"|"N"|"P"), (s+, ("E"|"I"|"A"|"N"|"P"))*) --
    endterms    IDREFS    #IMPLIED
    aggtrav        NAMES    agg
       -- lextype (("agg"|"mem"|"cor"), (s+, ("agg"|"mem"|"cor"))*) --
    context        (context|ncontext) ncontext
>

<!--FF-->

<!--
 _______________________________________________________________________
|                                    |
|    "Extra Structural" Module                    |
|                                    |
|    This module addresses markup designed for revision control    |
|    and internationalization (i18n)/localization (l10n) control.    |
|                                    |
|    These features are similar in that they are concerned with    |
|    markup of content that may span anything from a few characters    |
|    to many    elements (which need not be strictly hierarchically    |
|    synchronous).  Further, there may be many regions designated    |
|    as part of a revision, or with the same i18n/l10n        |
|    characteristics, but that should all be tied together (eg,    |
|    to indicate a single revision).                    |
|                                    |
|    The general markup technique is to identify a region of        |
|    content with an ID, create a separate "rev-description" or    |
|    "i18n-description" element that describes the revision or i18n    |
|    characteristic, and to name the IDs of the regions in the    |
|    rev-description/i18n-description content (to tie the        |
|    descriptions to the affected regions).                |
|                                    |
|    If a region of content to be identified is strictly        |
|    hierarchical, then it is already marked as some kind of        |
|    element, and the ID of that element should be (defined and)    |
|    used.  If a region is not hierarchical, then the author may    |
|    choose to mark up that region by using asynchronous tags -    |
|    two bracket tags, each with EMPTY content, that demark an    |
|    arbitrary region within a document.                |
|                                    |
|    The use of asynchronous tags to delimit a non-hierarchical    |
|    region of content is controversial, however, OSF believes    |
|    that the majority of regions will be hierarchical and not    |
|    require asynchronous tags.                    |
|                                    |
|    For those cases where the information to be marked is        |
|    non-hierarchical, it is logically possible to turn it into    |
|    hierarchical *segments*, each of which could be marked        |
|    hierarchically.  However, revision markup is inherently        |
|    transient, introduced in one snapshot and removed a few        |
|    snapshots later.  There is no clean way to reattach region    |
|    segments together after the revision regions have been        |
|    removed, leading to markup fragmentation over time.        |
|                                    |
|    It is also worth noting that as part as processing of these    |
|    regions, each start and end point can be treated as a "point"    |
|    independent of the other end, greating simplifying the        |
|    processing burden (especially as concerns asynchronous start    |
|    and end tags).                            |
|                                    |
|    An example of Revision Control Markup:                |
|                                    |
|    Ok, <rev-bracket id=r1>let's say that this tagged text        |
|    is to be designated by a certain revision<rev-bracket id=r2>.    |
|    The two tags in the previous sentence bracket the region.    |
|    Let's also assume that there is a section (with id section2)    |
|    that should be identified as part of the same revision to    |
|    this document.  In the <meta><desc-pool> section, there        |
|    should be the following markup:                    |
|                                    |
|       <rev-description class=enh CRnumber=123 release="1.1">    |
|        <occurrences>                        |
|            <occ-async start=r1 end=r2>            |
|            <occ-sync idref=section2>            |
|        </occurrences>                        |
|       </rev-description>                        |
|                                    |
|    This identifies the region bracketed by r1 and r2, as well    |
|    as the region with id section2 as being associated with        |
|    the enhancement request 123 and release "1.1".  Other        |
|    information can be included about the rev-description        |
|    through other attributes.                    |
|                                    |
|    There are a similar set of tags for i18n markup (i18n-bracket    |
|    and i18n-description).  Each <*-description> element is        |
|    specifically tailored for its own purpose.            |
|_______________________________________________________________________|
-->


<!--....................................................................
.    asynchronous bracket markers                    .
 .....................................................................-->

<!ELEMENT  ( i18n-bracket | rev-bracket ) - O    EMPTY    >

<!ATTLIST  ( i18n-bracket | rev-bracket )
    commentary    CDATA    #IMPLIED    -- any user commentary on this
                           bracket - not processed --
    %common-attr;        #REQUIRED
>


<!--....................................................................
.    description of a set of i18n, and revised regions.        .
 .....................................................................-->

<!ELEMENT i18n-description - O    ( ( (%s.leaf;)* | (%s.branch;)* ),
                            occurrences? )    >

<!ELEMENT rev-description - O    ( (%s.leaf;)*, occurrences? )        >


<!ATTLIST i18n-description
    %common-attr;        #IMPLIED
>

<!ATTLIST ( rev-description )
    class    CDATA        #REQUIRED
            -- takes:
                create    - a new file
                defect    - defect from OT
                enh    - enhancement (no code change)
                feature    - change caused by change to sw
                review    - caused by technical review
                misc    - no other appropriate class --

    CRnumber CDATA        #IMPLIED  -- bug tracking number --
    release     CDATA        #IMPLIED  -- version of doc in which fix
                         will first appear --
    mark    ( mark | nomark )    #IMPLIED  -- present a change mark? --
    delmark ( delmark | nodelmark )    #IMPLIED  -- mark the deletion? --
    %common-attr;        #IMPLIED
>


<!--....................................................................
.    occurrences contains a list of regions addressed by a        .
.    *-desc element.  It supports naming a set of hierarchical    .
.    regions (eg, an element) by using occ-sync, or a non-        .
.    hierarchical regions (marked by *-bracket elements).        .
 .....................................................................-->


<!ELEMENT occurrences - -    ( ( occ-async | occ-sync )+ )
            -- a list of regions (synchronous or asynchronous)
               associated with a *-description --
>
<!ATTLIST occurrences
    %common-attr;        #IMPLIED
>

<!ELEMENT occ-async    - O    EMPTY    -- async occurrence indicator --  >
<!ELEMENT occ-sync    - O    EMPTY
            -- sync (hierarchical) occurrence indicator --
>

<!ATTLIST occ-async
    start    IDREF    #REQUIRED    -- start bracket,
            reftype(i18n-bracket, rev-bracket) --
    end    IDREF    #REQUIRED    -- end bracket,
            reftype(i18n-bracket, rev-bracket) --
    %common-attr;    #IMPLIED
>
<!ATTLIST occ-sync
    idref    IDREF    #REQUIRED    -- names a region (no reftype) --
    %common-attr;    #IMPLIED
>

<!--FF-->
<!--
 _______________________________________________________________________
|                                    |
|    Production and Appearance Markup Module                |
|                                    |
|    While the main focus of the OSFDTDs is to capture semantic    |
|    information about a document's content, OSF still publishes    |
|    paper versions of its documents, and requires the ability to    |
|    markup certain appearance specifics in the document source.    |
|                                    |
|    Typically, the need for this markup arises during production    |
|    cycles of documents, but many of the markups can stay in the    |
|    source without downside.  For example, an imperative page    |
|    break often *should* be removed after production, as it is    |
|    unlikely that page breaks will fall exactly the same way    |
|    after the document is revised, but a "small capitals"        |
|    markup is related to the content, and should probably stay    |
|    in the source once added.                    |
|                                    |
|    We use a combination of markup techniques to implement these    |
|    appearance specs.  None is ideal, and there will be those    |
|    people who believe that none of this really belongs in SGML    |
|    at all.  We've tried to choose the least problematic method    |
|    for each markup.                        |
|                                    |
|    Here's a summary:                        |
|                                    |
|    PIs    We use processing instructions only when a single PI    |
|        will do the trick (we avoid matched pairs of PIs).    |
|        Also, we use PIs when we wish to avoid having the    |
|        markup apparent during regular editing of a document    |
|        (ie, a writer shouldn't generally see these things    |
|        while writing and marking up semantic content).        |
|                                    |
|    Attributes                            |
|        We provide a "full adjust/ragged right" attribute    |
|        on wrapping text regions (paragraphs and titles) to    |
|        handle the case where the default adjustment needs    |
|        to be overridden, perhaps because very long words    |
|        on a short output line cause unsightly intercharacter    |
|        white space.                        |
|                                    |
|    special-format element                        |
|        We've introduced an element (pretty much like key data,    |
|        and available generally where key data is available)    |
|        to handle the kind of appearance specifics that one    |
|        might see in an applications "property sheet" -        |
|        fonts, point sizes, etc.  Though generally non-        |
|        semantic, these are necessary if an author needs, for    |
|        example, to show an example of a specific font or    |
|        point size in a Style Guide book.  This element is    |
|        available as an inclusion at the s.branch level.    |
|_______________________________________________________________________|
 -->

<!--....................................................................
|                                    |
|    Processing Instructions                        |
|                                    |
|    The following PIs are for use when required for conducting    |
|    production work on a book.  Their use is deprecated in the    |
|    standard itself, and there is no guarantee that their        |
|    particular functionality is available in all processing        |
|    contexts.  By convention we start names with "osf-". Of        |
|    course there is no way to control their use in instances.    |
|                                    |
|    Note that all of these PIs should be inserted at the relevant    |
|    point in a document, and take no content of their own.        |
|                                    |
|    osf-new-page        start a new page here            |
|    osf-break        break line here                |
|    osf-hyphen        allow hyphenation here            |
|    osf-need N        need N lines at end of page            |
 .....................................................................-->




<!--....................................................................
|    Special-format is an element that can provide special        |
|    formatting to its content.  It is intended to be used for    |
|    paper document production, and is deprecated for other uses.    |
|    It is an inclusion to the following elements:            |
|        p, title, list, display, bridge-title, table        |
|                                    |
|    Note that this element uses the HyTime context attribute to    |
|    indicate that the content model of special-format should be    |
|    inherited from its parent in the instance - ie, it may take    |
|    only the same content model as its parent.            |
 .....................................................................-->

<!ELEMENT special-format - O    ( (%s.leaf;)* )        >

<!ATTLIST special-format
    font    CDATA            #IMPLIED  -- type face --
    size    NUTOKEN            #IMPLIED  -- point size --
    style    CDATA            #IMPLIED  -- italic, bold, etc --
    horizkeep (breakok | nobreak)    #IMPLIED  -- keep content on 1 line --
    smallcaps (smallcaps | nosmallcaps)    #IMPLIED  -- force size --
    context    (context|ncontext)    context      -- content model inherited --
    %common-attr;            #IMPLIED
>
<!--FF-->

<!--
 _______________________________________________________________________
|                                    |
|    Conditionals Module                        |
|                                    |
|    Documents that are part of OSF offerings often need the        |
|    to have content conditionally included or excluded, usually    |
|    based on the context in which the document is being processed.    |
|    For example, for those offerings that are built in different    |
|    ways with respect to Security (eg, B1 and C2 levels of        |
|    security), the documentation must be adaptable to the        |
|    software.                            |
|                                    |
|    Marked sections should be used by an author to delimit and    |
|    control conditional regions.  Because the use of marked        |
|    sections isn't explicitly controlled by a DTD, this module    |
|    doesn't contain declarations.  However, in the interests of    |
|    having a consistent approach to the use of marked sections,    |
|    this module prescribes how marked sections will be used in    |
|    OSF documents.                            |
|                                    |
|    1. Marked sections should be placed around the content that    |
|       is being conditionalized                    |
|                                    |
|    2. An entity name should be chosen to control the inclusion/    |
|       exclusion of the content.  The name should start with    |
|       the prefix "OSF.COND.".  An entity reference should be    |
|       placed in the "status keywords" portion of the marked    |
|       section introduction.                    |
|                                    |
|    3. An external entity should contain a list of definitions    |
|       of all the OSF.COND. entities that a document instance    |
|       uses, and that external entity should be referenced into    |
|       the document instance.                    |
|                                    |
|    4. Appropriate definitions should be chosen for the OSF.COND.    |
|       entities in the external entity.                |
|                                    |
|    5. [Special cases:]  An author may use an external entity with    |
|       a "hard-coded" (ie, not through an entity reference) status    |
|       keyword to insert a comment into a document, or to mark    |
|       SGML content that is intended to be shown, uninterpreted,    |
|       in the instance.                        |
|                                    |
|    OSF does not prescribe how the external entity (containing    |
|    the OSF.COND. definitions) is to be maintained.  Authors    |
|    may create it by hand, or may generate it using tools.  For    |
|    example, OSF, internally, intends to generate these entities    |
|    by using tools that can query the intended context in which    |
|    a document will be used.                    |
|                                    |
|_______________________________________________________________________|
-->
<!--FF-->
<!-- RCS IDs of modules
  book-hdr.mod,v         1.20
  copyright.mod,v        1.3
  entities.mod,v         1.66
  book-hier.mod,v        1.38
  ref-hier.mod,v         1.28
  meta.mod,v             1.32
  titles.mod,v           1.16
  paragraph.mod,v        1.19
  key-data.mod,v         1.36
  st-key-data.mod,v      1.37
  notes.mod,v            1.11
  lists.mod,v            1.36
  tables.mod,v           1.6
  displays.mod,v         1.22
  equations.mod,v        1.7
  hy-annot.mod,v         1.12
  hy-davenport.mod,v     1.17
  extra-struct.mod,v     1.14
  production.mod,v       1.2
  conditional.mod,v      1.1
-->